home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text1054.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  3.0 KB  |  71 lines
  1.  
  2. Doug here,
  3.  
  4. > BTW Adding the resolution stuff fixes the problem of changing mode with
  5. > BlowUP installed. (VSetScreen [or was it VSetMode] switches to the the
  6. > high-rez TC mode - so I get 640x480xTC on my machine...)
  7.  
  8. We are writing a new screen booster. It performs much better than the others.
  9. It doesn't kill your low-res modes, and it fixes the VSetScreen bug in NVDI.
  10. It also removes that annoying mono bug where the borders screw up all over
  11. the place. It even works with MagiC and even Geneva without screwing things up!
  12.  
  13. It also appears BlowUP doesn't calculate the horizontal registers properly,
  14. putting annoying limitations on the maximum achievable resolution on most
  15. monitors. This can result in 'bending' effects and compression near the edges,
  16. as well as darkened screens and other weird things.
  17.  
  18. The driver is finished (I'm using it now), but we are still working on the
  19. res-editing part...
  20.  
  21. > Yes, I managed to fix the floors - but the walls were all too short for
  22. > some reason. :/ Maybe this is because I didn't patch the DSP code?
  23.  
  24. This is something you might have difficulty with right now. The aspect-ratio
  25. calculations in BM make selecting a base window size a little more complex
  26. than it looks. I could remove the aspect ratio stuff but that impacts on
  27. other areas - RGB monitors in particular...
  28.  
  29. > My changes to the code are static and you have to reassemble (and patch the
  30. > DSP code) to get a new resolution, but it shows that there's no real
  31. > problem doing this.
  32.  
  33. > patch the DSP code? I didn't do this??
  34.  
  35. Bad Mood is already capable of working out the screen size on it's own - I've
  36. just omitted to explain how. :)
  37.  
  38. I'll explain how to do this after I get a chance to play with it again. It's
  39. been a while since I looked at it.
  40.  
  41. There are probably a few inconsistencies though, like multiple line-width
  42. variables etc.. this is due to returning to the code for an hour or so after
  43. several weeks (or months) away from it. Things get a bit disorganized...
  44.  
  45. :)
  46.  
  47. > Could whoever was going to implement the resolution changes, please, do it?
  48. > We don't need any fancy menu stuff at the moment. Another command line
  49. > switch would be quite fine.
  50.  
  51. > Yep - or perhaps a .cnf [or .ini] file...
  52.  
  53. This is what I was working on, but I think it was passed off some time
  54. ago as being a bit unfriendly. I produced an ini file describing which mode
  55. to use for which display selection. It also allows you to indicate where software
  56. emulation of 'big' pixels should be used when low-detail is enabled.
  57.  
  58. > I also tried turning off the floor/ceiling textures and I believe that
  59. > may be a good option for slower machines. IIRC Doom on the SNES does that.
  60.  
  61. Fair enough, but it won't save that much time. The DSP will still need to
  62. calculate and return all the relevant info for texturing the floors. This takes
  63. quite a bit of machine time even without drawing the textures.
  64.  
  65. It might be practical to strip down the DSP driver for flat-shading. There's
  66. not really enough room in there for two copies of several routines, and fudging
  67. it into the current driver would make things over-complicated.
  68.  
  69. Doug.
  70.  
  71.